Forms provide a convenient way for users to input data or interact with objects. Forms are generally created in a design application, for example ADOBE® ACROBAT® or ADOBE® LIVECYCLE® Designer, by a designer. When a user later wishes to use a form, the user renders the form in a reader application, for example ADOBE® ACROBAT® READER®. For example, a designer may design a form to be hosted on a website to allow a user to place a purchase order or to accomplish a workflow. The designer would create the form in a design application, then the form will be rendered by a reader application for use by a user. The reader application permits the user to use the form, such as to fill in fields, but limits the users ability to change the form. The form may include objects such as fields to be filled out by the user (e.g., billing information, delivery information, items to be purchased, etc.), objects that auto-fill in response to fields filled out by the user (e.g., calculations of total, tax, shipping, etc.), and objects that perform other actions (e.g., a button that submits the form to a backend database or emails the form to a merchant's email address). Forms provide a desirable user interface (“UI”) for many reasons.
Forms can also provide diverse and dynamic objects. For example, a form may include conventional objects, such as fields for user input and graphics for display to a user, and may also include more dynamic objects, such as buttons or controls. Forms may have associated scripts (e.g., JAVASCRIPT® scripts) that perform functions, such as importing data, populating fields, or performing other actions. Additionally, a designer of a form may secure the form, for example by encrypting the form using special features of a design application.
Conventional design applications have a portion of their UI configured for displaying to a user a “design view” of the form. The design view allows the designer to create the layout of a form and create or manipulate objects on the form. For example, a design view may show where objects, for example text fields or buttons, would appear on a completed form. The design view differs from the rendered view of a form in that the design view allows a designer to manipulate objects as the designer designs the form. For example, a designer may add objects, remove objects, move or modify the shape of objects, or modify how a user can interact with objects of a completed form. Once the form is rendered, a user may only interact with the form and may not modify objects on the form.
To create a useful form with even a moderate amount of functionality, the designer of the form writes scripts that may depend on one or more objects on a form and/or be activated by a user interacting with one or more objects on a form. Scripts add functionality to particular objects on a form, for example a script could be configured to change the background color of a field to red to indicate that its current value is invalid. Scripts can also work with multiple objects within a form, for example summing values of several fields and displaying the total in another field or emailing a form to an email address a user provided in a field. Scripts in a form can be executed in any number of ways, for example a script may be activated by an activation form object (e.g. a button) when clicked on by a user.
A designer generally writes and modifies scripts in a “script editor”. The script editor is generally viewed in a separate portion of the design program UI, for example in a pop-up window. For a designer to view the contents of a script (i.e., the code), the script editor must necessarily usurp real-estate from the design view (i.e., take away valuable screen space from the design view), thereby restricting the designer's view to a limited portion of the form or to a zoomed-out view of the form. The script editor also takes away space from any other windows that may be open, for example a window showing properties of an object.
Scripts often contain references to one or more form objects and are said to be dependent on those form objects. For example, if a “tax” field displays and calculates the amount of tax on a payment based on the value of a “rate” field that contains the tax rate as well as the value of a “payment” field that contains the payment amount, the script that calculates the “tax” field is said to be dependent on the “rate” and “payment” fields. Identifying and understanding dependencies between scripts is integral in building a form with even a moderate amount of functionality and complexity. The difficulty in identifying dependencies increases exponentially as a form becomes more complex and scripts depend on more and more form objects that span across multiple pages. For a designer to look through all scripts related to a form in the script editor to determine which objects each depends on is a very cumbersome task. This task of going through each script to determine dependencies is especially difficult for a designer who did not initially create the form but has been tasked with maintaining or updating it with new functionality.
Prior art systems, for example the system disclosed in U.S. Pat. No. 7,206,997 to Alden et al., teach that a functional visualization of a spreadsheet can allow users to visualize the relationship between cells of a spreadsheet. The system of Alden teaches generating an influence diagram with entities representing the cells of a spreadsheet, the influence diagram having arcs (e.g., arrows) connecting the entities corresponding to equations that may be entered in the cells. While this solution provides users with a visual representation of the relationship between cells, this method perpetuates the inconvenience of the script editor in that a portion of the UI must be used to display the influence diagram. Indeed, an influence diagram could be generated to visualize the functional relationship of objects on a form but at the cost of UI real estate.
The prior art system disclosed in U.S. Patent Application Publication 2006/0080594 of Chavoustie et al. teaches a different approach to providing a visualization of the relationship between cells on a spreadsheet. The system of Chavoustie provides labels in cells of a spreadsheet and graphical path lines between cells of a spreadsheet to show how equations relate cells of a spreadsheet. This approach overlays the functional visualization of the relationship between spreadsheet cells directly on a spreadsheet.
Forms are fundamentally different from spreadsheets. While spreadsheets arrange cells based on their relation, forms provide a completely free layout of objects and scripts may relate plural objects on a form. A designer of a spreadsheet chooses cell location based on the functional relationship of rows and columns while a designer of a form chooses object location based on convenience to a user of the form. Thus, a designer of a spreadsheet may understand the relationship of cells on the spreadsheet by their mere position, but designer of a form only deduces the relationship of objects by reviewing scripts that refer to the objects. Indeed, the full details of a cell's relationship to other cells are provided directly by the equation in the cell, while the functional relationship of a form object may be buried in several long and complex scripts.
Moreover, form objects are often related in ways other than through equations that cannot be effectively shown on a spreadsheet or even an influence diagram. Neither can show, for example, UI functions performed by form objects (e.g., an activation form object activating one or more scripts in response to a user action). For example, neither a spreadsheet, even with indications of cell relationships, nor an influence diagram can show the functional relationship a script may provide having a first UI control perform a function that may depend on one or more other form objects or a function that is modified based on a UI control.
Further, forms are also fundamentally different from spreadsheets in that they are designed in a design application and then used in a rendering application. The teachings of both Alden and Chavoustie may assist a designer or user of a spreadsheet with understanding and modifying equations in cells. However, these teachings provide almost no benefit to the designer of a form who must create and modify scripts. Additionally, these teachings not only provide no benefit to the user of a form, but would hinder a user's use of a form. A goal of forms is to provide a convenient interface for a user while completely hiding underlying operations from the user.
As scripts become more complicated they can easily grow to be thousands of lines and a single script can be dependent on many objects in complex ways. For example, scripts for performing dynamic actions, such as populating a drop-down-list object with data based on a user's input into other form objects or importing data from a file into a form, may be thousands of lines and may depend on hundreds of form objects. Accordingly, it is often difficult or cumbersome to troubleshoot and edit forms.